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DETAILED ACTION 

1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Champagne (US 7,310,730 B1) in view of Voit (US 6,798,751 B1). 

Regarding claim 1 

Referring to claim 1 Champagne discloses a method in an intermediate node 
comprising a multicast/broadcast server and a streaming node for providing multicast 
for streaming transmission from a streaming server to users of a multicast group with 
the multicast/broadcast server providing multicast transmission and with the streaming 
node providing a streaming transmission based on an on-demand single -user 
signaling supporting the transmission of a streaming flow, the method comprising the 
steps of (Abstract: A method of communicating an encrypted data broadcast to a plurality of 
virtual private network receivers is disclosed. A first communication channel is established 
between a first one of the receivers and a network node. A private data stream is communicated 
to the first receiver on the first channel. A request is received from the first receiver to join a 
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broadcast data stream that is directed to a plurality of receivers by a broadcast server. A second 
encrypted communication channel is established between the first receiver and the network node 
for purposes of carrying the broadcast data stream. Decryption information, which the first 
receiver can use to decrypt information that is sent on the second channel, is sent to the first 
receiver through the first channel. The broadcast data stream is then communicated to the first 
receiver on the second channel. As a result, a particular receiver can receive an encrypted 
broadcast that is encrypted as part of a single session for a large plurality of other receivers, 
without impacting separate, private encrypted communications conducted by the particular 
receiver.) (Col. 6 lines 8-1 8 In block 306, a request from the first receiver to join a broadcast is 
received. The request may be an HTTP or RTSP request. For example, network node 202 
receives a request from VPN client 2MB to join a broadcast data stream originating at broadcast 
server 102. VPN client 214B may provide the request to the network node 202 by relaying a 
selection of a link or UR-L associated with broadcast server 102 that is made by an end user at 
personal computer 1 16B. In this context, a M broadcast n or "broadcast event" refers to an event 
that ideally is multicasted, such as live streaming audio, video streaming, etc.) and (Fig. 2): 
establishing a bearer for a multicast transmission according to the requirements for 
streaming transmission (Col. 7 lines 1 1-22 In one particular approach, the broadcast event is 
unicast to each receiver using IPSec for encryption on the broadcast channel. Alternatively, the 
broadcasted event can be transmitted using generic routing encapsulation (GRE). In this 
approach, the broadcast sen/er 1 02 communicates the broadcast using multicast to all elements of 
LAN 104 or network 108 that support multicast, and uses unicast GRE tunnels for 
communication to clients through elements that do not support multicast. In this approach, for 
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efficiency, the network element that originates the unicast streams could cache the broadcast 
stream.), establishing a multi-user streaming session on the bearer by translating the on 
- demand ( e.g. Video -On-Demand) single -user signaling received from the 
streaming server into multi-user push signaling ( Col. 7 lines 33-36 In this environment, the 
ISP could store the broadcast event as a confidential file in a cache local to a particular set of 
users. Such users then could retrieve, as Video-On-Demand, the broadcast event stored in the 
cache, which would be sent by unicast to the users.). Champagne did not discloses adapting 
the received streaming flow to the multicast transmission according to the needs of a 
multicast group or subgroup of a multicast group, replicating the received streaming 
transmission according to the number of the multicast subgroups. The general concept 
of adapting the received streaming flow to the multicast transmission according to the 
needs of a multicast group or subgroup of a multicast group, replicating the received 
streaming transmission according to the number of the multicast subgroups is well 
known in the art as taught by Voit. Voit discloses adapting the received streaming flow 
to the multicast transmission according to the needs of a multicast group or subgroup of 
a multicast group, replicating the received streaming transmission according to the 
number of the multicast subgroups. (Col. 25 lines 45 -56 and Col 26 lines 1-6 For a multicast 
service, such as the satellite-originated video broadcast service, the service provider sends one 
stream through the vertical services domain network 13 to the L3/4 ATM switch 19. The switch 
19 will monitor every ATM virtual circuit going to the subscribers, looking for IGNP requests. A 
subscriber sends an IGNP request to join a selected multicast channel. When the L3/4 ATM 
switch 19 detects such a request, it identifies the requested channel and the requesting subscriber 
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equipment and forwards a 'join message to the vertical services domain. Subsequently, the 
switch 19 replicates received packets for the requested broadcast channel, and the switch drops 
the replicated packets into the cells for each of the virtual circuits of all of the joined subscribers, 
including the newly added subscriber. When the subscriber later elects to end viewing of the 
multicast, the subscriber's equipment sends a Meave* message, and the switch 19 stops adding the 
cells for the multicast to that subscriber's virtual circuit). It would have been obvious to one 
of ordinary skill in the art at the time of the invention to modify Champagne to include 
adapting the received streaming flow to the multicast transmission according to the 
needs of a multicast group or subgroup of a multicast group, replicating the received 
streaming transmission according to the number of the multicast subgroups in order to 
provide any bandwidth or delay guarantees 

Regarding claims 15 and 16 

Claims 15 and 16 are similarly rejected using at least the same reasoning /citations 
provided for claim 1 since they recite the same limitations and are distinguished only by 
statutory category. 

Regarding claim 2 

Referring to claim 2 Champagne and Voit discloses all the limitations of claim 2 which is 
described above. Champagne also discloses further comprising the step of the 
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streaming node communicating with the server adapts the streaming transmission and 
forwards the adapted streaming transmission to the multicast/ broadcast server (Col. 7 
lines 1 1-22 In one particular approach, the broadcast event is unicast to each receiver using 
IPSec for encryption on the broadcast channel. Alternatively, the broadcasted event can be 
transmitted using generic routing encapsulation (GRE). In this approach, the broadcast server 
102 communicates the broadcast using multicast to all elements of LAN 104 or network 108 that 
support multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that originates 
the unicast streams could cache the broadcast stream). Champagne did not discloses which 
replicates the received streaming transmission among subgroups of a multicast group. 
The general concept of replicates the received streaming transmission among 
subgroups of a multicast group is well known in the art as taught by Voit. Voit discloses 
replicates the received streaming transmission among subgroups of a multicast group 
(Col. 25 lines 45 -56 and Col 26 lines 1-6 For a multicast service, such as the satellite-originated 
video broadcast service, the service provider sends one stream through the vertical services 
domain network 13 to the L3/4 ATM switch 19. The switch 19 will monitor every ATM virtual 
circuit going to the subscribers, looking for IGNP requests. A subscriber sends an IGNP request 
to join a selected multicast channel. When the L3/4 ATM switch 19 detects such a request, it 
identifies the requested channel and the requesting subscriber equipment and forwards a 'join 
message to the vertical services domain. Subsequently, the switch 19 replicates received packets 
for the requested broadcast channel, and the switch drops the replicated packets into the cells for 
each of the virtual circuits of all of the joined subscribers, including the newly added subscriber. 



Application/Control Number: Page 7 

10/595,473 

Art Unit: 2154 

When the subscriber later elects to end viewing of the multicast, the subscriber's equipment 
sends a 'leave* message, and the switch 19 stops adding the cells for the multicast to that 
subscriber's virtual circuit). It would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify Champagne to include replicates the received 
streaming transmission among subgroups of a multicast group in order to provide any 
bandwidth or delay guarantees. 

Regarding claim 3 

Referring to claim 3 Champagne and Voit discloses all the limitations of claim 3 which is 
described above. Champagne also discloses the multicast/broadcast server i.e. server 
102 communicating with the server i.e. server 103 (Fig.2). Champagne did not discloses 
replicates the received streaming transmission among the subgroups of a multicast 
group and forwards each replicated streaming transmission to the streaming node, 
which adapts each streaming transmission. The general concept of replicates the 
received streaming transmission among the subgroups of a multicast group and 
forwards each replicated streaming transmission to the streaming node, which adapts 
each streaming transmission is well known in the art as taught by Voit. Voit discloses 
replicates the received streaming transmission among the subgroups of a multicast 
group and forwards each replicated streaming transmission to the streaming node, 
which adapts each streaming transmission. (Col. 25 lines 45 -56 and Col 26 lines 1-6 For a 
multicast service, such as the satellite-originated video broadcast service, the service provider 
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sends one stream through the vertical services domain network 13 to the L3/4 ATM switch 19. 
The switch 19 will monitor every ATM virtual circuit going to the subscribers, looking for IGNP 
requests. A subscriber sends an IGNP request to join a selected multicast channel. When the 
L3/4 ATM switch 19 detects such a request, it identifies the requested channel and the requesting 
subscriber equipment and forwards a 'join' message to the vertical services domain. 
Subsequently, the switch 1 9 replicates received packets for the requested broadcast channel, and 
the switch drops the replicated packets into the cells for each of the virtual circuits of all of the 
joined subscribers, including the newly added subscriber. When the subscriber later elects to end 
viewing of the multicast, the subscriber's equipment sends a ' leave' message, and the switch 19 
stops adding the cells for the multicast to that subscriber's virtual circuit). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify 
Champagne to include replicates the received streaming transmission among the 
subgroups of a multicast group and forwards each replicated streaming transmission to 
the streaming node, which adapts each streaming transmission in order to provide any 
bandwidth or delay guarantees. 

Regarding claim 4 

Referring to claim 4 Champagne and Voit discloses all the limitations of claim 4 which is 
described above. Champagne also discloses wherein a decision unit is provided for 
deciding how the received streaming flow is to be directed in the intermediate node. 
(Col. 7 lines 1 1-22 In one particular approach, the broadcast event is unicast to each receiver 
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using BPSec for encryption on the broadcast channel. Alternatively, the broadcasted event can be 
transmitted using generic routing encapsulation (GRE). In this approach, the broadcast server 
102 communicates the broadcast using multicast to all elements of LAN 104 or network 108 that 
support multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that originates 
the unicast streams could cache the broadcast stream). 

Regarding claim 5 

Referring to claim 5 Champagne and Voit discloses all the limitations of claim 5 which is 
described above. Champagne also discloses wherein the streaming nodes have 
different capabilities and the multicast/broadcast server knows the different capabilities 
and addresses of the streaming nodes in order to select an appropriate streaming node 
for performing an appropriate adaptation of the streaming flow. (Col. 7 lines 1 1-22 In one 
particular approach, the broadcast event is unicast to each receiver using IPSec for encryption on 
the broadcast channel. Alternatively, the broadcasted event can be transmitted using generic 
routing encapsulation (GRE). In this approach, the broadcast server 102 communicates the 
broadcast using multicast to all elements of LAN 104 or network 108 that support multicast, and 
uses unicast GRE tunnels for communication to clients through elements that do not support 
multicast. In this approach, for efficiency, the network element that originates the unicast streams 
could cache the broadcast stream.) and ( Col. 7 lines 58-62 In another approach, network node 
202 may maintain a table of network address of known nodes that send broadcasts. Packets 
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received at network node 202 are then examined and a lookup in the table is performed to 
determine if a broadcast node is sending the packets). 

Regarding claim 6 

Referring to claim 6 Champagne and Voit discloses all the limitations of claim 6 which is 
described above. Champagne also discloses wherein in case a hierarchical coding (e.g. 
encryption) is used the streaming flows are differentiated in sense that a different 
number of layers is sent to different streaming nodes. (Col. 7 lines 47-57 In block 406, a 
broadcast event is detected. For example, network node 202 detects that broadcast server 102 has 
initiated a broadcast. Such detection may be performed using several approaches. For example, if 
the broadcast sen/er 102 is multicasting the broadcast event, the network node may automatically 
detect that such an event requires a common encryption scheme for all VPN users. Alternatively, 
if the broadcast server does not use multicast, the VPN concentrator can detect that a broadcast 
event is occurring from request information in the protocol layers of event packets above the IP 
layer.) and (Col. 8 lines 33-41The strength of encryption performed by common channel 
encryption engine 220D can vary. For example, the VPN concentrator can implement policy- 
based encryption based on the Layer 3 or Layer 4 attributes of the traffic generated by the 
broadcast server. As a specific example, network node 202 may examine the type of request 
received from the VPN client 214B and determine that for a phone conference meeting, 64-bit 
encryption is used, whereas for a company all-hands meeting, 128-bit encryption is used, etc.) 
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Regarding claim 7 

Referring to claim 7 Champagne and Voit discloses all the limitations of claim 7 which is 
described above. Champagne also discloses wherein the intermediate node 
administrates an address identifying the streaming flow arriving from the server. (Col. 7 
lines 47-57 In block 406, a broadcast event is detected. For example, network node 202 detects 
that broadcast server 102 has initiated a broadcast. Such detection may be performed using 
several approaches. For example, if the broadcast server 102 is multicasting the broadcast event, 
the network node may automatically detect that such an event requires a common encryption 
scheme for all VPN users. Alternatively, if the broadcast server does not use multicast, the VPN 
concentrator can detect that a broadcast event is occurring from request information in the 
protocol layers of event packets above the IP layer.) and ( Col. 7 lines 58-62 In another approach, 
network node 202 may maintain a table of network address of known nodes that send broadcasts. 
Packets received at network node 202 are then examined and a lookup in the table is performed 
to determine if a broadcast node is sending the packets). 

Regarding claim 8 

Referring to claim 8 Champagne and Voit discloses all the limitations of claim 8 which is 
described above. Champagne did not discloses wherein the intermediate node 
receives a session description message informing about the transmission parameters 
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required for the streaming session and forwards the received parameters to the group 
members by means of the multi-user push signaling message. The general concept of 
wherein the intermediate node receives a session description message informing about 
the transmission parameters required for the streaming session and forwards the 
received parameters to the group members by means of the multi-user push signaling 
message. (Col. 17 lines 32 The network 10 also supports communications over one or more 
logical application paths 36 to local applications 37 hosted in the vertical services domain. 
Assuming that a subscriber with various equipment 25 also subscribes or otherwise participates 
in one or more of the vertical services, the local carrier (e.g. Bell Atlantic in FIG. 3) offers a 
corresponding number of additional application SLAs with the customer. Each SLA for a vertical 
service may specify QoS parameters for the particular application, such as rate/bandwidth, 
latency, jitter, packet loss, packet sequence, security and/or availability. Examples of such 
applications hosted in the carrier's vertical services domain 37 include the illustrated voice over 
IP service shown as a V/IP gateway, as well as video services and some caching for high volume 
local web services. Communications for such applications utilize the one or more paths 36.). It 
would have been obvious to one of ordinary skill in the art at the time of the invention to 
modify Champagne to include wherein the intermediate node receives a session 
description message informing about the transmission parameters required for the 
streaming session and forwards the received parameters to the group members by 
means of the multi-user push signaling message in order to provide any bandwidth or 
delay guarantees. 
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Regarding claim 9 

Referring to claim 9 Champagne and Voit discloses all the limitations of claim 9 which is 
described above. Champagne did not discloses wherein the intermediate node 
receives a session description message informing about the transmission parameters 
required for the streaming session and said intermediate node changes the received 
parameters according to the needs of the subgroups that receive a dedicated replicated 
stream and sends the changed parameter to the group members by means of the multi- 
user push signaling message. The general concept of wherein the intermediate node 
receives a session description message informing about the transmission parameters 
required for the streaming session and said intermediate node changes the received 
parameters according to the needs of the subgroups that receive a dedicated replicated 
stream and sends the changed parameter to the group members by means of the multi- 
user push signaling message is well known in the art as taught by Voit. Voit discloses 
wherein the intermediate node receives a session description message informing about 
the transmission parameters required for the streaming session and said intermediate 
node changes the received parameters according to the needs of the subgroups that 
receive a dedicated replicated stream and sends the changed parameter to the group 
members by means of the multi-user push signaling message. (Col. 14 lines 59-67 and 
Col . 15 lines 1-7 Returning to the discussion of the CO 1 1, the structure and operation of each 
DSLAM 17 is essentially the same as those of the DSLAM 1 1 1 in the embodiment of FIG. 9, 
except that the control functionality of the DSLAM 17 is somewhat different. The DSLAM 17 
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controls the ATU«Cs to implement a rate-adaptive ADSL service, to adapt operations so as to 
maximize data rates for the communications over the individual subscriber lines. Essentially, the 
ATU-Cs and ATU-Rs signal each other over the lines to synchronize their modes of operation at 
parameter settings, which achieve optimum data throughput. Also, the DSLAM 17 does not need 
to monitor or limit the line rates, but instead relies on the rate-adaptive control algorithm to 
maximize the rates achieved over the ADSL circuits or provide rate-shaping for the ATM virtual 
circuits. Other network elements limit rates, where necessary. It would have been obvious to 
one of ordinary skill in the art at the time of the invention to modify Champagne to 
include wherein the intermediate node receives a session description message 
informing about the transmission parameters required for the streaming session and 
said intermediate node changes the received parameters according to the needs of the 
subgroups that receive a dedicated replicated stream and sends the changed 
parameter to the group members by means of the multi-user push signaling message in 
order to provide any bandwidth or delay guarantees. 

Regarding claim 10 

Referring to claim 10 Champagne and Voit discloses all the limitations of claim 10 which 
is described above. Champagne did not discloses wherein nodes higher up in the 
hierarchy are informed that the streaming flow is only to be forwarded to a single node 
lower in the hierarchy by means of a new message being distribute along the multicast 
delivery tree. The general concept of nodes higher up in the hierarchy are informed that 
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the streaming flow is only to be forwarded to a single node lower in the hierarchy by 
means of a new message being distribute along the multicast delivery tree is well known 
in the art as taught by Voit. Voit discloses nodes higher up in the hierarchy are informed 
that the streaming flow is only to be forwarded to a single node lower in the hierarchy by 
means of a new message being distribute along the multicast delivery tree. (Col. 25 lines 
45 -56 and Col 26 lines 1-6 For a multicast service, such as the satellite-originated video 
broadcast service, the service provider sends one stream through the vertical services domain 
network 13 to the L3/4 ATM switch 19. The switch 19 will monitor every ATM virtual circuit 
going to the subscribers, looking for IGNP requests. A subscriber sends an IGNP request to join 
a selected multicast channel. When the L3/4 ATM switch 19 detects such a request, it identifies 
the requested channel and the requesting subscriber equipment and forwards a Join message to 
the vertical services domain. Subsequently, the switch 19 replicates received packets for the 
requested broadcast channel, and the switch drops the replicated packets into the cells for each of 
the virtual circuits of all of the joined subscribers, including the newly added subscriber. When 
the subscriber later elects to end viewing of the multicast, the subscriber's equipment sends a 
Teave v message, and the switch 19 stops adding the cells for the multicast to that subscriber's 
virtual circuit). It would have been obvious to one of ordinary skill in the art at the time of 
the invention to modify Champagne to include nodes higher up in the hierarchy are 
informed that the streaming flow is only to be forwarded to a single node lower in the 
hierarchy by means of a new message being distribute along the multicast delivery tree 
in order to provide any bandwidth or delay guarantees 
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Regarding claim 11 

Referring to claim 1 1 Champagne and Voit discloses all the limitations of claim 1 1 which 
is described above. Champagne also discloses wherein the conversion between single- 
user on-demand and multi-user push signaling implies that certain messages are not 
propagated. (Col. 1 lines60-67 and Col 2 lines 1-4 Further, communicating broadcast media 
information using a VPN tunnel may significantly reduce the amount of bandwidth available to 
the VPN end user for other communications. Such end users may need to perform other kinds of 
communication such as email, telnet sessions or HTTP browsing using information that is 
specific to a particular end user. Because broadcast media typically have high bandwidth 
requirements, communicating such broadcasts on a large number of VPN sessions may exceed 
the maximum available encryption throughput of the VPN device. As a result, end users may be 
unable to communicate the user-specific information when a broadcast is in process). 

Regarding claim 12 

Referring to claim 12 Champagne and Voit discloses all the limitations of claim 12 which 
is described above. Champagne did not discloses wherein the replication of the 
streaming flow is based on an access network, in which users are located or/ and on the 
geographic area and /or on the Quality of Service a subgroup wishes for streaming 
sessions. The general concept of the replication of the streaming flow is based on an 
access network is well known in the art as taught by Voit. Voit discloses the replication 
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of the streaming flow is based on an access network, (Col. 25 lines 45 -56 and Col 26 lines 
1-6 For a multicast service, such as the satellite-originated video broadcast service, the service 
provider sends one stream through the vertical services domain network 13 to the L3/4 ATM 
switch 19. The switch 19 will monitor every ATM virtual circuit going to the subscribers, 
looking for IGNP requests. A subscriber sends an IGNP request to join a selected multicast 
channel. When the L3/4 ATM switch 19 detects such a request, it identifies the requested 
channel and the requesting subscriber equipment and forwards a 'join message to the vertical 
services domain. Subsequently, the switch 19 replicates received packets for the requested 
broadcast channel, and the switch drops the replicated packets into the cells for each of the 
virtual circuits of all of the joined subscribers, including the newly added subscriber. When the 
subscriber later elects to end viewing of the multicast, the subscriber's equipment sends a 1 leave 
message, and the switch 19 stops adding the cells for the multicast to that subscriber's virtual 
circuit)., in which users are located or/ and on the geographic area and /or on the 
Quality of Service a subgroup wishes for streaming sessions (Col. 35 lines 33-51 FIG. 12 
provides a flowchart that summarizes the steps taken by the CPE in forwarding Ethernet frames 
to the ADN. In step 1202, an Ethernet frame is received at one of the interface ports. The 
Ethernet frame encapsulates datagrams. Information related to an upper-layer protocol is 
extracted, in step 1204, from the received frame. Examples of such information include the 
destination IP address encapsulated within the Ethernet frame. A set of rules (e.g., a routing 
table) is consulted to determine, in step 1206, what ethertype encapsulation needs to be used 
based on the extracted upper-layer information. Once the ethertype encapsulation method is 
identified, the datagram is re-encapsulated, in step 1208, using the identified ethertype 
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encapsulation method. Once encapsulated, the frame, in step 1210, is forwarded upstream over 
the ADN. In performing the forwarding step (step 1210) the CPE can also consult security access 
control lists to identify permissible connections and sessions and block Ethernet frames when 
appropriate. Similarly, the CPE can also perform the forwarding step in a manner to ensure 
conformance with any QoS parameters associated with the upstream bandwidth.). It would have 
been obvious of one of ordinary skill in the art at the time of the invention to modify 
Champagne to include wherein the replication of the streaming flow is based on an 
access network, in which users are located or/ and on the geographic area and /or on 
the Quality of Service a subgroup wishes for streaming sessions in order to provide any 
bandwidth or delay guarantees. 

Regarding claim 13 

Referring to claim 13 Champagne and Voit discloses all the limitations of claim 3 which 
is described above. Champagne also discloses wherein the intermediate node requests 
the actual characteristics of the area in order to adapt the streaming flow accordingly. 
(Col. 7 lines 1 1-22 In one particular approach, the broadcast event is unicast to each receiver 
using IPSec for encryption on the broadcast channel. Alternatively, the broadcasted event can be 
transmitted using generic routing encapsulation (GRE). In this approach, the broadcast server 
102 communicates the broadcast using multicast to all elements of LAN 104 or network 108 that 
support multicast, and uses unicast GRE tunnels for communication to clients through elements 
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that do not support multicast. In this approach, for efficiency, the network element that originates 
the unicast streams could cache the broadcast stream). 



Regarding claim 14 

Referring to claim 14 Champagne and Voit discloses all the limitations of claim 3 which 
is described above. Champagne discloses wherein the intermediate node provides 
additional information to the charging /billing server in order to guarantee an accurate 
charging and /or multi-user streaming related charging. (Col.26 lines 35-52 Although IP- 
based, the services from the vertical services domain 13 may follow any other desirable business 
model. For example, a multicast service provider may contract with the carrier to provide 
multicast audio (radio-like) and/or video (TV-like) services via the vertical services domain. The 
multicast service provider, not the subscribers, would pay the carrier. The multicast service 
provider may offer any or all of the multicast programming to customers on some type pay-per- 
view basis but would likely offer most of the programming service for free or bundled in as part 
of some nominal monthly subscription charge . The multicast service provider instead would 
charge advertisers in a manner analogous to current broadcast business practices. Advertising 
distributed with the IP multicasting, however, can be carefully targeted at end-customers having 
demographic profiles meeting specific criteria specified by individual advertisers, which allows 
the multicast service provider to charge premium advertising rates. ) and (Col.26 lines 16-34 In 
an enhanced service offering, the broadcast provider could offer a convenient navigation 
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interface from a web server. The server could be on the vertical services network, but preferably 
is on the wide area Internet 1 1 . With a PPPoE session active, the user can surf to the provider's 
server and view information about available programming. The user might select a current 
broadcast program by clicking' on a URL link in the provider's web-based information. 
Although provided through the wide area Internet 1 1, the URL would actually contain the private 
IP address for the desired broadcast program available from the vertical services network 13. 
Selection of such a URL therefore would generate a message to the appropriate server on the 
vertical services network 1 1 to initiate the above discussed procedure to allow the user to 'join 
the selected broadcast. A similar methodology might also enable a provider to offer menu, 
selection an d order/billing services from the Internet 1 1, to provide pay-per-view or video on- 
demand type services from the vertical services domain network 13). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify 
Champagne to include the intermediate node provides additional information to the 
charging /billing server in order to guarantee an accurate charging and /or multi-user 
streaming related charging in order to provide any bandwidth or delay guarantees. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ashley d. Turner whose telephone number is 571-270- 
1603. The examiner can normally be reached on Monday thru Friday 7:30a.m. - 
5:00p.m.. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan Flynn can be reached at 571-272-1915. The fax phone number for 
the organization where this application or proceeding is assigned is 571-270-2603. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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